fix(security): report the CSP floor before enforcing it - #3455

#3417 shipped the platform CSP floor enforced. It blocked, on every hosted
project that loads an asset the platform does not itself emit, every one of
those assets at once. A fleet audit finds ~100 projects in that state --
stock photography (images.unsplash.com, i.pravatar.cc, picsum.photos), video
(player.vimeo.com, vjs.zencdn.net), object storage (storage.googleapis.com),
embeds (www.youtube.com) -- including veryfront's own marketing site. Only two
projects, codersociety and tomcode, declare `security.csp` at all.

The owner gets no signal beyond a browser console, and no remedy short of a
republish: `security.csp` lives in project config, and a hosted project serves
config from its deployed release, so editing it changes nothing until the next
publish. codersociety hit exactly this -- added the three directives it needed
at 04:57, still served the bare floor hours later because its production
release was cut in June.

So the floor reports before it enforces. A project that has declared
`security.csp` has demonstrably looked at its policy and keeps the enforced
header; everyone else gets `Content-Security-Policy-Report-Only`, which
surfaces identical violations without breaking the page. The reported policy
is byte-identical to the enforced one, so what a project sees now is exactly
what it will get later -- there is a test pinning that.

Two escape hatches stay enforced: `VERYFRONT_CSP_ENFORCE` flips the default
once adoption is high enough, and a full `VERYFRONT_CSP` override is enforced
because writing one by hand is already an explicit ops act.

An empty `csp: {}` counts as opt-in. The signal is that the project touched the
key, not how much it put in it; reading emptiness as "unconfigured" would strand
a project that deliberately accepted the floor in report-only forever.

This is a narrow, time-boxed relaxation, not a retreat: the floor was enforced
for roughly one day, so report-only restores the state the fleet was already
in rather than weakening a settled protection.

`content-security-policy-report-only` joins the policy-owned header list, so a
project-provided value cannot survive into a response whose policy the platform
is deciding.

Verified: full unit suite green -- 3811 passed, 27995 steps, 0 failed. Three
handler tests read the policy header directly and now accept either name; they
assert nonce alignment, not enforcement mode. deno check, lint and fmt clean.

Three follow-ups to the same behaviour change, all found by CI rather than by
the unit suite -- integration tests are not part of `test:unit`, which is what
was run locally.

Four assertions in the production-server integration tests read
`content-security-policy` directly. Their fixtures declare no `security.csp`,
so the floor now reaches them report-only. They assert policy content and
nonce alignment, not enforcement mode, so they read whichever header carries
the policy via a local `readCsp` helper. The mode itself is covered by
dedicated cases in the unit tests.

`cspHeaderName` is no longer exported. Nothing outside this module calls it --
it was exported only out of habit, and exporting it widened the public API
surface and the generated reference for no gain.

Regenerate `docs/api-reference/veryfront/security.md`: adding the enforcement
helper shifted the line pins the reference cites. Regenerated with the same
Deno the CI check pins (2.7.7), never hand-edited.

Review catch on the report-only change, and a pre-existing hole it would have
widened.

`applySecurityHeaders` ends by writing every `security.headers` entry straight
onto the response. Every other name that loop can touch has a deliberate
override path through `getHeaderOverride` -- Referrer-Policy, X-Frame-Options,
and so on -- so re-setting them is the intended behaviour. CSP has no such
path: it is computed from the platform floor merged with `security.csp`, and a
value arriving through `security.headers` silently replaced the whole policy.
That was already true before this branch; adding a second delivery name meant a
project could also flip whether the policy is enforced or merely reported.

Skip both CSP names, case-insensitively, and warn once when one is dropped so
the project learns where the policy actually comes from.

`isSecurityPolicyResponseHeaderName` is deliberately not reused for the check.
It covers the whole policy-owned set, including the headers this loop is still
meant to override; matching on it would silently remove working overrides.
Worth noting that helper currently has no call sites at all, so the "server
integrations must remove project-provided values" contract its doc comment
describes is not enforced anywhere -- out of scope here, but it is why this had
to be handled at the point of use.

Three tests cover it: a project CSP value is ignored while its `security.csp`
still merges, the report-only name is ignored case-insensitively, and the
legitimate overrides plus arbitrary custom headers still land.

Also correct the integration helper comment: `VERYFRONT_CSP` and
`VERYFRONT_CSP_ENFORCE` select enforced delivery too, not just a `security.csp`
declaration.

Verified: 80 steps in the security-handler suite, 0 failed.

Adding the enforcement helper and the CSP header guard shifted the line pins
the generated reference cites. Regenerated with the Deno the CI check pins
(2.7.7); never hand-edited.